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ABSTRACT 


In order for the METOC community to remain 
operationally significant and engaged with the war 
fighters, decision makers and other customers, METOC 
products and services must be fully integrated into the 
systems that these various groups depend on for there daily 
information. This thesis investigates ways to make METOC 
product and services more interoperable by utilizing net 
centric concepts to improve the tactical significance of 
METOC products, accessibility to data, and interoperability 
between internal command systems. 

Improvements where made to the Joint METOC Viewer and 
METCAST systems to improve the ability of the programs to 
provide tactically significant products and data 
accessibility. Additionally, developments were made to 
create an interoperable Electronic Ship Eolder Database and 
Message Parsing Program that allows all Optimum Track Ship 
Routing (OTSR) data to be organized into one system that 
can be used to parse, track and disseminate OTSR related 
information. 
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INTRODUCTION 


I. 


In recent years, the Department of Defense (DoD) 
shifted from a threat-based model to a capabilities-based 
model for military operations (CJCS, 2000) . This shift 
occurred because we no longer know with any certainty where 
or how our military resources will be required. The 
evolution of a capabilities-based military, as outlined in 
the Joint Vision 2020 (CJCS, 2000), requires that our 
military be more mobile, flexible, and interoperable 
(joint) then ever before. Today, Network Centric 
Operations (NCO) has become an important means to provide 
information to decision makers. Our military can now 
quickly exchange and process information so that navy goals 
such as munitions on target and expedient routing of ships 
around storms can occur. 

This change of focus is as relevant to the Meteorology 
and Oceanography (METOC) community as it is to "Big Navy". 
Today we provide things like satellite images or weather 
briefings in stand-alone PowerPoint slides, but this must 
change. These new times mandate that we become more 
integrated and interoperable with the decision makers and 
warfighters. By increasing its interoperability, the METOC 
community will "remain strategically engaged and become 
significantly more operationally and tactically aligned by 
providing decision makers with knowledge that is specific 
to the warfighter platform, system, weapon, etc." 
(Oceanographer of the Navy, 2002) . 

This new business model will force the METOC community 
to modify the way it provides current products and 
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services, requiring new methods and tools to create new 
products and services. Today, our computer software 

programs and services in the METOC community have been 
largely developed by local commands. This resulted in very 
good programs like the Joint METOC Viewer (JMV), Naval 
Oceanographic Data Dissemination System (NODDS), Online 
Messaging System (OMS), or the current OTSR tracking 
databases, that met the local command requirements, but are 
not interoperable with the warfighter or other METOC 
commands. Current application that provide data to the 
fleet like JMV, GEMPL, TAWS, AREPS, IMAT, NOWS, Access, 
Word, Excel, Notepad provide static pictures or text 
products that require a man in the loop to process and 
present the product to the customer. 

A. STATEMENT OF THESIS GOALS: 

The goal of this thesis is to improve interoperability 
of METOC product and services by: 

1. Enabling the forecaster tool of choice, the Joint 
METOC Viewer (JMV), to produce products (ESRI Shape 
formatted Horizontal Weather Depictions (HWD) and ship 
tracks) that can be displayed on a tactical display. 

2. Improving the METOC product dissemination tool, 
METCAST, to allow easy transfer of Regional Center created 
products (HWD's and ship tracks) to customers, staffs, and 
other Regional Centers. 

3. Upgrading existing Optimum Track Ship Routing 
(OTSR) database into an Electronic Ship Eolder that would 
not only make all OTSR Centers more interoperable, but 
increase the efficiency of the database by including all 
elements of the OTSR system (e.g., message support. 
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database tracking, automated report/metrics generation and 
automated web page production). 

Each of these individual projects improves the ability of 
the METOC community to better serve itself and the fleet 
with more timely, accurate and tailor-made products. This 
thesis also proposes a concept of operations for how future 
METOC (possibly more mesoscale) products can and should be 
provided. 

B. INTEROPERABILITY WITH THE WARFIGHTER 

Today, only a few METOC products, such as high winds 
and high seas warnings, tropical forecasts and NAVO REACT 
products are produced in a format that can be displayed on 
the warfighter display systems (e.g.. Global Command & 
Control System (GCCS), ESRI ARCVIEW/ARCINEO). In an effort 
to increase the interoperability of METOC products with 
tactical displays, improvements have been made to JMV to 
allow viewing of HWD's and ship tracks in ARCVIEW and 
Polexis Viewpoint. This process was tested during EBE-J as 
part of the Geospatial Enhanced METOC (GEM) program being 
coordinated by the center in San Diego. Although this 
project only tested a limited subset of METOC products, it 
has established the CONORS and determined problem areas for 
developing additional capabilities. 

C. IMPROVED COMMUNICATIONS FOR REGIONAL CENTER PRODUCTS 

Traditionally, Navy METOC Regional Centers have 
produced products either in a text-based format for 
transmission over the Navy's messaging system or graphical- 
based formats that were pushed to a web site. These data 
formats were adequate for support within a particular 
centers Area of Responsibility (AOR); however, when support 
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for a command crossed traditional AOR boundaries, no simple 
method existed to produce a consolidated product. As a 
result, staffs and regional centers where forced to brief 
multiple slides or manually recreate products from other 
centers, wasting valuable resources. In this effort, 
improvements were made to the METCAST Channels system to 
allow multiple products from multiple product producers to 
be quickly and easily uploaded and downloaded. Now 
disparate or geographically separated products can be 
merged to create single consolidated basin, hemispheric or 
global products. The scope of this thesis is to conduct 
this process using HWD's and ship tracks. HWD's and Ship 
tracks traditionally are two important METOC products that 
require coordination between centers and are required by 
centers, and by Operational and Type Commanders. 

D. ELECTRONIC SHIP FOLDER 

The OTSR program, which will be discussed more in 
Chapter II, is operated by various centers around the globe 
and provides cost savings and storm avoidance services for 
vessels transiting large ocean basins. Running an OTSR 
program requires that Regional Centers have ways to 
retrieve and view current weather data, monitor operational 
message traffic, track the requested OTSR support, and 
supply the latest OTSR data to appropriate commanders. 
Although the end product of the OTSR process for Regional 
Centers is identical, current support methods differ from 
center to center causing inefficiencies and database 
mismatches. As a ship transits from one AOR to another, 
data entered into one database must be manually replicated 
to the database at the second regional center. To improve 
the interoperability in this program a comprehensive 
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Electronic Ship Folder system has been developed that will 
improve the maintenance of the OTSR program and improve 
interoperability between regional centers. The scope of 
this project will include a database for support tracking, 
message dissemination tools to automate some data entry, 
and upgrades to JMV and METCAST that allows easier product 
development and dissemination. 
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II. PROGRAM AND SERVICE OVERVIEW 


This chapter will discuss the programs used in this 
thesis, JMV and METCAST and provide a brief description of 
the basic structure of a NMOC Center OTSR program. The 
deficiencies discussed will be confined to only issues 
related to JMV, METCAST and the distribution of HWD and 
Ship route products 
A. JMV 

1. Background 

JMV is a program developed by SPAWAR and Eleet 
Numerical Meteorology and Oceanography Center in Monterey, 
CA. JMV is compatible with the Microsoft Windows OS 
family. Sun Solaris and HPUX. JMV is used to display 
gridded model data, satellite imagery, surface and upper 
air observations, along with many other types of 
meteorological and oceanographic data (ENMOC, 1999) . The 
gridded data that is displayed can be viewed in standard 
contour maps or as horizontal and vertical cross-sections. 
To formulate a forecast, raw data can be overlaid with 
METOC symbology to produce meteorological products (e.g., 
HWD's, Analysis Charts, High Winds and Seas) as well as 
situational awareness and analysis tools (e.g.. Ship Tracks 
and Storm Tracks) . JMV is the backbone for current Naval 
meteorological forecasting; used in Ocean Basin and 
Operations Area (OPAREA) forecasting. Ship routing (OTSR), 
Elight forecasts using the Optimum Path Aircraft Routing 
Software (OPARS) , airport observations and forecast 
display. 


7 



2 . 


Deficiencies: 


In the production of tactically relevant products or 
the automatic generation of Center "value added" products, 
JMV needs to have the capability to output shape formatted 
products and be able to add manually generated products to 
the slide show feature. 

a. Tactically Relevant Products 

The ability to know where your forces are in 
relation to your enemy is extremely valuable. Force 
locations combined with current intelligence (e.g., troop 
movements, missile launches, signal detection, etc.) and 
weather is vital to mission planning and execution. The 
Navy GCCS system provides the common operational picture 
(COP) used to display real-time and near real-time battle 
space information. Recently the Naval Special Warfare 
(NAVSPECWAR) Command began to use commercial products 
(e.g., ARCINFO, ARCVIEW, ARCGIS) from ESRI that allows geo- 
located and ortho-rectified information (satellite images, 
chart and map products, tactical Products) to be overlaid 
on the same display. In order to fuse METOC products 

into the tactical picture, the METOC community must produce 
products in compatible formats. In July 2002, DoD awarded 
a contract to ESRI for the Combined Joint Mapping Tool Kit 
(CJMTK) that may become the next Generation COP by year 
2012. The METOC community only provides High Winds, High 
Seas and Tropical Warnings to the current GCCS COP. 
Additionally, some Naval Oceanographic Office products are 
being produced in shape format for use in ESRI's ARC 
Products. Minor upgrades to JMV will allow us to produce 
meteorological products into ESRI's shape format and thus 



allow METOC products to be viewed directly by NAVSPECWAR 
and the future COP. 

b. Auto Generation of NMOC Center "Value Added" 
Products 

JMV's Slide Show production capability allows 
users to create presentations used for analysis or for 
creating weather products for customers. Presentations are 
produced by combining various types of METOC data like 
satellite images, gridded model data, observations, and 
combined on a common background map display. Data is 
automatically updated whenever the latest METCAST download 
occurs. Data is retrieved using METCAST, the 

publish/subscription service, from the Tactical 

Environmental Data Server (TEDS), located at ENMOC or any 
of the Regional Centers. Although these products are 
useful for the meteorologist to use for comparing the 
various model output with satellite data and local analysis 
products, they are not particularly useful to the novice 
who just wants to know basic weather, like visibility or 
temperature. These novice customers are actually provided 
with an interpretation of the model and satellite data that 
is prepared by the METOC Regional Center called "value 
added products". Unfortunately these "value added 

products" are not currently part of TEDS and METCAST. 
Today they are merely saved to a local server or hard drive 
thus JMV and METCAST do not know they are available and can 
not update the slide show presentation. The result of this 
deficiency is that personnel from the center must recreate 
the product from scratch. If JMV were aware of the "value 
added products" and automatically updated web pages it 
could save many hours of tedious and redundant work. 
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B. METCAST 

1. Background 

METCAST is a standards based, request-reply and 
subscription system used for distributing weather and 
oceanographic data. The METCAST System is made up of the 
METCAST Servers located at ENMOC or at any of the Regional 
Centers located around the globe and the METCAST Client 
that is used by the local user. Data is delivered by 
METCAST over the Internet, NIPRNET or SIPRNET using Hyper¬ 
Text Transfer Protocol (HTTP) and Multipurpose Internet 
Mail Extensions (MIME). METCAST users interact with the 
program by using the METCAST Client Graphical User 


Interface 

(GUI) 

1 , which 

allows a user 

to select 

a region 

of 

interest, 

the 

products 

to be retrieved, as 

well as 

the 

frequency 

and 

type of 

retrieval. 

Once the 

region 

and 


product types have been created, the region is scheduled 
for download and the retriever process is started which 
establishes the communications path between the METCAST 
Client (user interface) and the METCAST Server. 

METCAST currently has two methods of retrieving data 
via the METCAST Client. The request-reply is used for 
requesting established products from the METCAST Server, 
which are typically model output, satellite imagery, and 
observational data that ENMOC produces or collects and then 
distributes. The other method of data retrieval is to use 
the METCAST Channels where METCAST clients can publish and 
retrieve many different data types ranging from center 
generated forecasts, documents, PowerPoint presentations or 
simple text files. The advantage of this method is that 
METCAST Clients can publish information at will and as long 
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as the required attribute information is provided the 
product will be validated and posted to the channel. Once 
the product is posted, it is available to anyone who has a 
METCAST client or any other product that has access to the 
METCAST Server (i.e., Polexis Viewpoint). As stated in the 
introduction, one of the goals of this thesis was to 
improve the interoperability within the community and the 
METCAST Channels provide quick access to products between 
centers, staffs and the warfighter. 

2. Deficiencies 

The original version of the METCAST Channels server 
required that each channel contain only one type of data 
(e.g., text products, jpg graphics, gif graphics, 
PowerPoint presentations, etc.) and that only one version 
of each type of product exist at one time. Additionally, 
the METADATA or attributes available to sort the data was 
insufficient to provide easy access to the intended data. 
These restrictions meant that if this system were to be 
used to provide OTSR Ship Track data for a particular 
regional center, then a new channel would need to be 
created for every published ship track. Since each of the 
three Centers that provide OTSR services continuously track 
anywhere from 20 - 100 ships, the maintenance on this type 
of system would quickly become unmanageable. Consequently 
the METCAST Channels server must be modified to allow 
additional attributes to be associated with each product 
type and each Channel must be able to hold multiple 
products with unlimited attributes. 
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C. OTSR 

1. Background 

OTSR, which is operated by the Regional Centers in 
Norfolk, VA; San Diego, CA; and Yokosuka, Japan is a 
program used by the Navy for storm avoidance and cost 
savings during long ocean basin transits. OTSR is an 
advisory program, which minimizes damage to both personnel 
and material by constantly monitoring the atmospheric and 
oceanographic conditions throughout the world's oceans and 
providing continuous support to Naval, U.S. Coast Guard, 
DoD support and contract vessels, as well as authorized 
foreign vessels. 

In order to maintain an OTSR program, a center must 
have a way to send and retrieve message traffic, retrieve 
and view current weather data, track the requested support, 
and supply the latest support metrics to the appropriate 
commanders. Every center can send and retrieve message 
traffic either by using Gateguard or the Defense Message 
Dissemination System (DMDS). Additionally, all centers 
display weather data using JMV and retrieve their data 
either using METCAST or by downloading thumbnails from the 
ENMOC website (NIPRNET or SIPRNET). Today, differences 
exist in the tracking mechanism and metrics generation 
between the three OTSR centers. Each center maintains its 
own independent program, using its own methods of tracking 
(database, spreadsheet, etc.) and watch-to-watch turnover 
procedures. However, all centers use OTSR folders to track 
routing information for each vessel. These folders are 
usually maintained by the OTSR officer or tech and contain 
some, if not all of the following information: 
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1. Ships OTSR request message or MOVREP 

2. Picture of the ships track (usually plotted from 

JMV) 

3. Observational messages 

4. Forecast messages (WEAX or AVWEAX) 

5. OTSR messages (Surveillance, Advisories, Divert 
messages) 


6. Operational messages (OPREPS, Towing Reports, 
SITREPS) 

7. Any other pertinent information about the vessel 


Since OTSR support is provided on a daily bases, and 
information is passed from watch to watch, a database or 
spreadsheet is maintained to track the latest information 
on the ships and provide turnover between watch sections. 
Metrics are provided in many different formats such as 
spreadsheets and PowerPoint presentations. Some centers 
provide web pages with tracking information but 
unfortunately no consistent standard exists. 

2. Deficiencies 

Vessel tracking and metrics collection mechanisms 
differ from center to center. Database systems which, track 
the current support need to be more robust to provide 
latest ship information like observations, operational 
messages, WEAX/AVWEAX messages and all required message, 
graphics and current statistics. This information should be 
provided to appropriate commanders in an easy to read, 
standard format using an external or internal website. 
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III. SOFTWARE DEVELOPMENT, OPERATING PROCEDURES 
AND PRODUCT DISTRIBUTION OVERVIEW 


This chapter describes the upgraded features of JMV 
and METCAST and the Message Parsing Program and Electronic 
Ship Eolder Database. Detailed information about the 
function of the entire system will be provided in Chapter 
IV. 

A. JMV/METCAST UPGRADES 

JMV is a forecaster tool used by nearly every Navy 
forecaster, around the globe. New requirements are 
continually satisfied as enhancements are added to the 
program. A goal of this thesis was to improve the 
interoperability of tactical and non-tactical products 
created using JMV and dissemination of those products using 
METCAST. The concept of operations (CONOPS) for this effort 
concentrated on two products, HWD's and Ship Tracks. 
The concept proven here can be applied to any METOC 
product. 

1. JMV Upgrades 

Over a six-month period, modifications to JMV 3.6 were 
made to make products more tactically relevant and to 
enable easier transfer of these products to customers. 
Additionally, changes were made to the slide show feature 
of JMV to allow ship tracks to be automatically generated 
and available for web publishing. 

a. HWD and Ship Track Creation/Publishing 

The primary change to JMV/METCAST was the ability 
to create and publish products to a METCAST channel. Eor 
this implementation, we used a METCAST server on SIPRNET 
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located at FNMOC. A user-friendly interface was developed 
that allows users to create and publish JMV overlays. 
Interfaces for publishing finished products were added to 
the existing HWD's and Ship Route portions of JMV. Since 
the interfaces remained essentially the same, very little 
training is needed to exploit this new functionality. 
Forecasters use the same drawing tools they already use 
daily to create HWD's, High Winds Warnings, and High Seas 
Warnings and now can publish the product using the new 
publish capability. Products are created using JMV 

graphical tools that allow a user to draw a feature and 
then save the product (See Figure 1). 



Figure 1: Saving a Drawing in JMV 

If a user wants to publish a product to a METCAST 
Server, products are created in the same way but the user 
selects the Publish Drawing option (see Figure 2). 
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Figure 2: Publishing a Drawing in JMV 


Product attributes must be specified when you publish to 
provide database cataloging and product selection for 
subscribers. The significance of attributes in METCAST 
channels will be discussed later. Figures 3 and 4 show 
dialogs used to collect the required attribute data. The 
attributes are then automatically sent to the channel using 
a utility program called wshove.exe. 
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Figure 4: Publishing Dialog Box 2 of 2 


Ship Track data is added to the server in a 
similar manner, however, rather than the publish feature 
being added under the File menu, it is added directly to 
the ship route editor. Users publish a ship track to the 
server by first selecting the track in the ship route 
editor and pushing the publish button. Dialog boxes are 
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similar to those for HWD's. Figures 5 through 7 show the 
steps required to submit a ship track to the server. 
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Figure 5: Ship Track Publisher 
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Figure 7: Ship Track Publish Dialog 2 of 2 

Once the file is placed on the server it is 
available to the METCAST client for download. Products are 
formatted in XML and comply with the Task Force Web Portal 
initiative. XML is well suited for making the product 
interoperable with other systems. More discussion about how 
the data is retrieved from the server will be provided in 
the METCAST server and client sections. 

b. Automatic Product Generation 

The upgrades to the existing slide show builder 
will reduce the amount of man-hours required to build 
customized value added products. Although JMV was able to 
produce slides using METCAST data along with the value 
added products, locally generated products do not cause the 
slide show product to automatically update. This issue 
was solved for ship tracks by modifying JMV's slide show 
capability. Now whenever a ship track is opened in the Ship 
Route Editor, the presentation will be updated. This 
feature will be added to the other value added products 
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like HWD's in the near future. For more information on 
creating slide show see FNMOC, JMV 3.5 Help. 

2. METCAST Upgrades 

a. METCAST Server 

The METCAST server is a publish/subscription web 
service used to distribute data via the World Wide Web. 
Using METCAST, a user can publish products, define the 
catalog attributes, and delete products if authorized. 
Data consumers use the METCAST catalog to discover what 
data is available, and then, based on the discovered 
content subscribe to the required data. Data modified and 
published by the producer is then automatically sent to the 
consumer. In this case, the METCAST generic channel 
capability was used to send HWD's and ship routes. METCAST 
also contains fixed channels for know data types like 
forecast grids, imagery and observations. The original 

channel architecture only allowed one product type or MIME 
type per channel (i.e., product format; text, XLM, grids, 
PowerPoint, etc.). The new architecture allows a channel 
to contain multiple MIME types and an unlimited number of 
descriptive attributes. Queries are made based on desired 
attributes or, if desired, a user can request contents of 
the entire channel. With this version of METCAST channels, 
nearly unlimited customization is possible for any 
arbitrary data. METCAST channels provide a very flexible 
and arbitrary data publish/subscription service. In any 
given implementation, a concept of operation is required if 
users are to exercise this capability. In our case 
approximately 20-30 different channels were established for 
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similar data formats. For additional information on the 
METCAST Channels Server see the documentation at 
http://WWW.metnet.navy.mil/~spawar/JMV-TNG/Metcast- 
Channels.html. 

b. METCAST Client 

The METCAST Client provides a user interface to 
the METCAST Server (Eigure 8) . Using the METCAST client 

users can retrieve available products from channels. 
METCAST provides several Graphical User Interfaces (GUI) 
specifically designed for grids, observations and images. 
Eor channels a more generic Graphical User Interface (GUI) 
was developed. To access the Channels dialog box, click on 
Options and then Channels menus with the METCAST Client 

(See Eigures 8 and 9) . Select the Channels option and an 

interface (Eigure 10) opens that allows you to select the 
channel associated with a product. HWD's are stored in the 
annotated product display channel and the ship tracks are 
stored on the ship route channel (classified and 

unclassified servers). When a user accesses a channel, 
they have the option to retrieve the entire channel or only 
retrieve information based on a certain search criteria. 
The criteria that is used for the search is based on the 
attributes associated with each product. Again, the 

attributes are determined when the product is created and 
uploaded. METCAST attributes can be either mandatory or 
optional but for the HWD's and ship route products, all 
attributes are mandatory. Eigures 10 through 13 shows how 
a user selects the available channel, the required 
attribute type and the specific attribute value. Once 
complete the user is ready to retrieve the product. Each 
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retrieval can be scheduled for an on demanded, periodic or 
scheduled download (see FNMOC, JMV 3.5 Online Help for 
specifics). When channel products are downloaded, they are 
routed to MIME handlers specified in the mailcap file. 
This process is part of the http protocol and specified by 
Borenstein, 1993. 

Mail handlers are also referred to in the METCAST 
documentation at http://zowie.metnet.navy.mil/~spawar/ 
Briefs/Jmv-tng/HTTP-Ref.html. Based on these mechanisms, 
HWD's are placed in the \jmvwin\noddsfIsXglobalhwd 
directory and the ship routes are placed in the 
\jmvwinXnoddsfIsXtracks directory. To display the product 
in JMV, follow the procedures for displaying a drawing or 
ship route, respectively in ENMOC, JMV 3.5 Online Help. 
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Figure 9: Accessing Channels Dialog Box 



Figure 10: 


METCAST Channels Dialog Box 
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Figure 13: Retriever Setup 

3. Tactical Products 

Another significant addition made to JMV was an 
ability to export JMV products in ESRI's shape format. 
Shape allows different types of geo-referenced data to be 
added to a common map background. ESRI provides 

Geographical Information Systems (GIS) mapping Services for 
numerous governments and commercial agencies worldwide. In 
the summer of 2002, ESRI was awarded a contract for the 
Commercial Joint Mapping Toolkit(C/JMTK) that can be used 
to overlay military data over NIMA maps. Using this 

capability, the METOC community can now feed meteorological 
and oceanographic data directly onto decision makers 
displays. 

In this demonstration, the user must export an XML 
file that is then converted to a Shape file using a stand 
alone program. This conversion process is either spawned 
automatically using a MIME helper application or manually 
from a command line. In the future, we should incorporate 
the export shape capability directly into the JMV 
interface. The program is activated manually as follows; 
open a Windows command window (Eigure 14) and change the 
directory to drive:\jmvwin\noddsfls\globalhwd. Type the 
command xml2shape "filename".xml, where filename is the 
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actual name of the xml HWD file. The xml2shape.exe makes 
up three files, the first file (.shp) contains the latitude 
and longitude of the points, lines and polygons that will 
be generated, a second file (.shx) gives an index to the 
shp file and the third files (.dbf) is the database file 
that contains the attributes associated with each of the 
shp files. Since each graphic is created from both lines 
and polygons, the A files contain the line data and the B 
files contain the polygon information. JMV/METCAST moves 
the files into the \ jmvwin\noddsf Is directory. The user 
opens the JMV display map and then opens the shape file by 
selecting "File", "Open Shape File List" from the menu. A 
dialog allows users to select the appropriate shape file 
which is then displayed on the map background. The shape 
files are black and white because ESRI assigns arbitrary 
color files when initially loaded. A second file (ARCVIEW 
3.2,.avl file) is required to associate colors to the shape 
file if colors in ARC View are desired. Until the format 
of this file is better understood, the current xml2shape 
file is unable to generate this file. These files can be 
created manually within any of the ARC products and 
associated to an HWD or ship route file. 
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Figure 14: Activating XML2Shape.exe through Command 

Prompt 


In addition to shape, XML (Extensible Markup Language 
- a standard format for the web enabled Navy) formatted HWD 
and ship route files are uploaded to the METCAST Channels. 
XML files can be displayed by the Polexis XIS Viewpoint 
software and newer version of ESRI Arc View. These 
functions are currently undergoing testing as part of the 
Geospatial Enhanced METOC (GEM) program in San Diego. 
Polexis provides encoders and decoders needed to fuse METOC 
data into the U.S. Navy's COP. 

B. MESSAGE PARSING PROGRAM 

The Message Parsing Program scans incoming text 
formatted messages and, based on a search word hierarchy 
and user preferences, parses messages into an Access 
database for the Electronic Ship Eolders, JMV formatted 
Observations and MOVREPS, and moves messages to a specified 
directory if required. 

1. Program Requirements 

The program is written in Visual Basic and runs on 
Windows 2000 or higher. The program is called parser.exe 
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and requires two text files, plist.dat and activeship.txt, 
that are located in the program home directory. Two 
additional files, parsedata.dat and admin.dat, are created 
during setup and provide the necessary search criteria and 
configuration data. 

2. Program File Descriptions 


The parser.exe file is the executable program of the 
Message Parsing Program. This program parses the available 
message traffic into the specified formats. In order for 


the program 

to work 

, several 

secondary files are used 

to 

provide the 

search 

criteria. 

locations of the 

available 

directories, 

port list, and 

the name and route 

number 

of 

the OTSR supported 

vessels. 

The following is 

a list 

of 


required files and a description of their operation: 

1. activeship.txt: The activeship.txt file is 
created in order to connect the messages sorted by the 
parser program with the ships being supported in the 
Electronic Ship Folder. This file is exported by the 
database with the route number and ship name separated by a 
comma (Ex. S2002100, USS Shipname) . The format for the 
route number is Station Letter (S = San Diego, N = Norfolk 
and Y = Yokosuka) followed by the four-value year and 
finally the sequential route number (numbers start at 1 at 
the beginning of each calendar year). 

2. plist.dat: The plist.dat file contains all the 
ports around the world, along with the associated latitude 
and longitude. This file is used when a MOVREP is parsed 
and the ETA or ETD line of the message does not contain the 
latitude and longitude information. 

3. parsedata.dat: The parsedata.dat file, created by 
the parser.exe file, contains the search parameters and 
parsing criteria. This file is created when the program is 
installed and initialized with the first search parameter. 
The file is a random access file or indexed file that 
allows the information within the file to be quickly 
accessed and read into and out of the user interface. A 
text editor should never be used to manually edit this 
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file, as this will make the file unusable by the Message 
Parsing Program. 

4. admin.dat: The admin.dat file contains the 
configuration data for the program. The configuration data 
holds the command name, command location, and all the 
directories for the parsed data files. These directories 
can all be pointed to the same location or to different 
locations depending on how the administrator of the program 
wishes the files to be stored. 

5. p_log.dat: The p_log.dat file is a log that 
contains the actions of the program as it scans each file. 
The following data is stored in the log file: 

A. Time of scan 

B. Original file name 

C. Ship Name 

D. Date-Time-Group of Message 

E. Logcode. The logcode is a string of 
characters that show all the various steps that the program 
took to parse the file, as well as any problems that may 
have occurred. The possible messages are: 

1. Parsed to Database. This means that the 
data within the file was parsed into the Electronic Ship 
Eolder format and was placed in the mess.txt file. 

2. Eailed to Parse JMV Eile, the file is in 
strDir, where strDir is the directory where the file was 
placed. This error occurs when too many missing variables 
were detected when the observation or MOVREP files were 
parsed. The file is moved to a temp directory and can be 
modified by the user and reprocessed. 

3. MOVREP Parsed to JMV. The MOVREP was 
properly parsed into the JMV format and the file was copied 
into the specified JMV directory and named 
SHIPNAME_DTG. shp, where SHIPNAME is the name of the 
originator of the message and DTG is the date-time-group of 
the message. It is recommended that all ship routes be 
sent to the tracks directory within your primary 
jmvwinXnoddsfis directory. 

4. MOVREP not parsed, ETD, ETA, VIA, POS or 
MODLOC not found. This error occurs when a MOVREP file is 
parsed and neither the ETD, ETA, VIA, POS or MODLOC key 
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words are found. Usually, when this occurs the MOVREP is 
an arrival or update message and would not need to be 
placed into JMV. 

5. OB not parsed. Missing 99. This error 
occurs when the 99 specifying the location of the latitude 
group is missing from the observation. If the 99 is 
missing than the parser cannot locate the different 
sections of the code since it is using the 99 to determine 
where the information should be located within the code. 
In some case the 99 may be in the message, however extra 
spaces may be between the Latitude group and the previous 
code group. 

6. OB parsed to JMV. The observation was 
properly parsed into the file jmvobs.dat located in the 
specified JMV Directory. 

7. File moved to strDir, where strDir is 
the name of the directory where the file was placed. 

8. Search Phrase provides the key word that 
was found in the message. 

9. No search phrase found, file moved to 
General Folder. This message means that none of the search 
words in the parsedata.dat file where found in the message 
and now the program has defaulted to move the message in to 
the database as general and the text file has been moved to 
the general folder. 

F. Code for whether search parameter was found 
(1 = yes, 0 = no) 

6. Mess.txt: The mess.txt file is the message export 
file, which is read into the Electronic Ship Folder. This 
file is generated when the messages are parsed. When the 
file is read into the database, this file is deleted and 
recreated by parser.exe. 

3. Installation 

The Message Parsing Program (Fig. 15) operates in 
conjunction with the Electronic Ship Folder Database and 
both programs should be placed in the same directory for 
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easy operation. Directory selection is dependent on user 
preference and can be used in stand along mode on a single 
computer or stored on a network drive. Although the 
database is designed to be accessed by multiple users, the 
Message Parsing Program should be utilized by one computer 
system at a time (i.e., OTSR Router or Tech computers). To 
install the Message Parsing Program, add the parser.exe and 
plist.dat file in your directory and then export the list 
of active ships from the database (see Electronic Ship 
Folder Database, Program Operation) . 



Figure 15: Message Parsing Program User Interface 

4. Description of User Interface 

Once the program is installed and all required files 
are available, the program can be run by double clicking on 
the parser.exe file. The user interface shown in Figure 15 
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is the primary screen of the Message Parsing program. In 
order to understand how data should be entered into this 
form one will need to understand the purpose of each of the 
sections. 

a. Program Header 

Figure 16 shows the program header where users 
must decide what term the program will look for and what 
will be done to the message once that particular term is 
found. The first object of the form is the "Select Profile 
Name" drop-down list. From the drop-down list the user can 
view all the Profile Names for each of the search phrases. 
Each profile can be viewed by selecting the appropriate 
item from the drop-down list. 

The "Profile Name" is a unique identifier of the 
search phrase being looked for. Since the search phrase 
may not be unique if "Secondary Selection Criteria" is also 
being used, the profile name must be something that helps 
the user remembers what the particular profile does. If 
users enter two of the same profile names, an error will be 
produced and the user will need to change the name before 
the profile will be saved. 

The "Search Phrase" is the exact term that will 
be scanned for in the message. Since the term must be an 
exact match to the string found in the messages, in order 
for the message to be parsed, users may need to use several 
forms of the same string idea to get all the associated 
messages (e.g., SURFACE OBSERVATION, SUREACE OB, SURE OB, 
SRE OB) . In order to create these different phrases, 
several profiles will need to be created with unique 
profile names for each. 
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The last object in the header is the "Parsing 
option" box. This box controls what features are available 
for data entry. If the user selects one or all of the 
available check boxes then the dialogs below the header 
will become enabled. In the parsing options box, users 
have the option to move the file, parse the message to the 
database, parse the message to JMV or add a secondary 
selection criteria. 



Figure 16: Message Parsing Program Header 

b. Buttonology 

As seen in Figure 15, there are several buttons 
along the right-hand side of the program that allow the 
user to Add Profile, Edit Profile, Copy Profile, Remove 
Profile, Save Profile, Exit, Edit Admin and Parse Messages. 
Depending on the current action that the user is trying to 
perform, some or all of the buttons may be available for 
the user to select. The meanings of each of the buttons 
are self-explanatory, however the method for adding or 
editing a profile is not necessarily so. When the program 
is initially opened the program window will look like 
Eigure 15 with most of the screen disabled, the text boxes 
blank and the objects under the header locked. This 
ensures that the profiles will not be changed accidentally. 
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If a users wishes to view the list of profile names then 
they can select the drop-down list and click on the 
appropriate profile name. Once the profile is selected the 
information stored for that profile will be visible, 
however the boxes will remain disabled and locked. If the 
user wishes to change the profile, the Edit Profile button 
should be selected and then all objects that have checks in 
the header will be enabled and unlocked (Fig. 17). If the 
Profile Option in the header is not selected, then the 
associated box below the header will not be enabled. 



Figure 17: Example of an Editable Profile 

c. Entering Data into the Move File Frame 

The Move File frame (Fig. 18) is where the user 
can specify where a parsed message should be moved to and 
how the file should be named. Depending on the message 
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type, different pieces of information may be available from 
the message itself or the activeship.txt file, which can be 
attached to the filename to help make the file more 
identifiable than just using a standard naming convention. 
The move file frame interface provides the text box to 
enter a directory name and then provides two methods to 
specify the filename. If the user selects Preformatted, 
the filename will be created by selecting from the list of 
available options. Using this method, the user can create 
either a dynamic filename that is unique for every message 
or a static filename that will overwrite every time a new 
message is received. If the user selects Manual, then the 
user can type in the filename that will overwrite any 
previous message. For either choice, if the message is 
also parsed to the database, a copy of the original message 
will be saved in the database. 
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Move File Dialog box from Message Parsing 
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Figure 18: 









d. Required Header Info 


The "Required Header 

Info" 

frame 

(Eig. 

19) 

is 

used to determine whether 

the 

ship 

name 

should 

be 

the 

Originator or the Addressee 

(ADDE). 

In the case 

of 

an 

observation, the Originator 

of 

the 

message 

would 

be 

the 


ship name. However, if the message were a weather forecast 
message (WEAX) to an individual ship, then the ADDE would 
be the ship name. When a message is parsed the information 
created from this field is used to determine the vessel's 
name and compares that to the activeship file to see if 
that vessel is being supported. If the vessel is being 
supported and route number was selected to be part of the 
filename, then the route number is inserted into the 
filename. 


Required Header Info 

Is fhe Ship Name fhe Originator or Adde? 

C Originator 
Adde 

Eigure 19: Required Header Erame 

e. Database Frame 

The Database frame (Eig. 20) is used to clarify 

what database message type the file should be added to, if 

the file should always be saved in the specified "Move" 

directory and finally provides the starting and ending 

string that forms the information which is added to the 

database. The six message types equate to the six database 

types in Eigure 20. The yes check box provides the user the 
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ability to move messages from ships, not currently being 
supported, to a different director from those that are 
being supported. If this box is selected than messages 
from vessels not being supported will be moved to the 
External Message directory. This helps to separate the 
vessels that are in the AOR with vessels that are outside 
the AOR. Finally, the First Search String and Last Search 
String provide the key words that cause the parser to parse 
out the required text string from the message. In most 
cases, the first search string should be the search phrase 
you are looking for, but in some cases another string my do 
better. If the first search string is not the same as the 
search phrase, the first search string must follow the 
search phrase in the message. If the first search string 
precedes the search phrase then the text will never be 
found and the message will not parse. 
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Figure 20: Database Frame 
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f. JMV Frame 

The JMV frame (Fig. 21) provides the JMV format 
that the message will be parsed into. Currently the parser 
only supports MOVREP's and BBXX formatted messages, however 
future versions of this program or others like it should be 
able to parse OTSR Requests and observations that do not 
contain the BBXX label. When parsing either a MOVREP or a 
BBXX message, select the appropriate JMV selection and then 
provide a directory string for where the files should be 
placed. All MOVREP files are placed in the appropriate 
directory with a shipname_dtg.shp format where shipname is 
the name of the vessel and dtg is the date-time-group of 
the message. Observations are place into the appropriate 
directory and combined into one file called jmvobs.dat. 
Because JMV has separated Sea Synoptic files for every area 
that is created within JMV, the jmvobs.dat file will need 
to be manually appended to the SEA SYNOPTIC 
REPORT^OS^^^^^O^N^S^.JMV file, located in the directory of 
the area one is using whenever the latest observations are 
needed. If a user does not know what area they are using 
from JMV, the area name is located in the top left hand 
corner of the JMV display screen (Eig. 22) that they use to 
display JMV products. 
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Figure 21: JMV Parsing Frame 
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Figure 22: JMV Map Display Screen for Area NEWPAC 
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5. Adding Configuration and Parsing Criteria 

Once the parser.exe, plist.dat and activeship.txt are 
all placed in the designated directory, the program is 
ready to be initialized by adding configuration data. To 
add configuration data, click on the button labeled "Edit 
Admin" (see Fig. 15) to open the administration form (Fig. 
23) . Once in the administration form is open, enter the 
command name and Location. Enter this information in the 
same format as the commands Plain Language Address (PLA). 
Next, enter the directory locations were the individual 
messages would be stored once they are processed. These 
directories can all be the same path or different paths as 
shown in Figure 23. While entering the directories into the 
administration form, ensure that all directory paths end 
with the "\". Error checking is installed to ensure that 
the path contains this slash, however, as a general rule 
all paths should end with a slash. 
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Figure 23: Form Used to Enter Configuration Data 


Now that the configuration data is added, it is time 
to beginning adding the parsing criteria. Since a method 
of prioritizing the criteria is not available for this 
version of the program, care and planning should be given 
to the order that each criterion is added. As a general 
rule, priority should be given in the following order: 

1. Individual search terms that will be received from 
vessels (e.g., BBXX, Surface Ob, OTSR Request, OTSR Report, 
etc. ) 


2. Individual search terms with secondary search 
criterion set for your command. 

3. Individual search terms with secondary search 
criterion set for other commands. If you have a priority 
for other commands, place the commands with the highest 
priority higher in the list. 
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As an example of how this list should be prepared, the 
following short list would be for NPMOC San Diego. 

1. BBXX 

2. SURFACE OB 

3. SURF OB 

4. WEATHER OB 

5. WX OB 

6. MOVREP 

7. MOVEREP 

8. WEAX FOR, SECONDARY: NAVPACMETOCCEN SAN DIEGO CA 

9. WEAX UPDATE FOR, SECONDARY: NAVPACMETOCCEN SAN 
DIEGO CA 

10. WEAX FOR, SECONDARY: NAVPACMETOCCEN YOKOSUKA JA 

11. WEAX UPDATE FOR, SECONDARY: NAVPACMETOCCEN 
YOKOSUKA JA 

12. TROPICAL CYCLONE, SECONDARY: NAVPACMETOCCEN PEARL 
HARBOR HI 

Remember, that if a search word is not found or the 
secondary selection criterion is not found than the message 
will be given a general message type and be parsed into the 
general folder. If you are not concerned with having 
another centers message parsed to a specific location or 
given a specific message type (OBS, OTSR, WEAX, OPS, etc.), 
do not add them to the list. 

6. Program Operation 

Once the configuration and parsing data have been 
entered into the system, the program can be run by placing 
the files in the designated drop directory and manually 
activating the "Parse Messages" button. Occasionally, 
errors occur with a particular file that causes the program 
to stop operating. In most cases the filename will appear 
in an error box. To continue the parsing process, remove 
the file and press the parse messages button again. Once 
the parsing program is complete a message box will open 
telling you that you have successfully parsed all the 
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available messages. Click the OK button and leave the 
program open for the next round of parsing. Once you have 
completed the parsing process it is a good idea to go ahead 
and import the messages into the database (See Program 
Operation under the Electronic Ship Folder section). 

C. ELECTRONIC SHIP FOLDER DATABASE 

The Electronic Ship Folder (ESF) Database (Fig. 24) is 
designed to be the one stop data location for the OTSR 
router. The database provides data entry and access 
capability to customer, support, and message data. 
Additionally, the program has the capability to provide 
links to valuable METOC data such as satellite images, 
overlaid model verification products, Meteograms and many 
other products which can be produced using JMV's slide show 
builder, WSI or Terascan. Once the support information has 
been entered, html web pages, metrics and reports can be 
automatically generated from the existing data. 
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Figure 24: Electronic Ship Folder Start Form 

1. Program Requirements 

The database used to create the ESF is run on Access 
2000 and requires Microsoft Windows OS running Microsoft 
Office 2000 or Microsoft Office XP to operate. Since 
databases have a tendency to become very large, the machine 
that is used to store the database should have several 
hundred MB's of available storage. 

2. Program File Descriptions 

The database program is made up of four files that are 
responsible for maintaining the data, controlling the 
security access, providing the ingestible data, or 
containing the exported data. 
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1. ESF.mdb: The database file is the esf.mdb file 
that contains all the Forms, Tables, Queries, VBA Modules 
and Reports that are used by the program. 

2. System.mdw: The system.mdw file controls the 
security access to the program. This level of security is 
not meant to keep people out of the database since the 
program will be on a secured network, but instead to log 
access to the database. 

3. Mess.txt: This file is created by the Message 
Parsing Program and contains all the message traffic that 
has been received by the center. This file is used by the 
OTSR router to view incoming message traffic and ease data 
entry procedures. 

4. Activeship.txt: Activeship.txt is exported from 
the database once some data has been entered into the 
system and ships are under active support from the OTSR 
Center. 

3. Installation 

To install the ESF program, copy the esf.mdb and 
system.mdw files into the same directory where the 
parser.exe file was copied. Now that the files are copied 
to the correct directory, the security parameters need to 
be updated. Find wrkgadm.exe usually located in the 
C:\programfiles\Microsoftoffice\office\1003\ directory. If 
the file is not located in this directory, run a search on 
wrkgadm.exe to find the file. Once you find the file, 
double-click on it and a Workgroup Administrator window 
(Fig. 25) will open. Click on join to open the Work Group 
Information file (Fig. 26) and browse to find the 
system.mdw file located in the directory with the ESF 
database file. Once the correct system.mdw file is 
selected, select OK. Figure 27 should now be seen; close 
this window and press exit on the Figure 25. 
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Workgi oup Adininistrator 


Name; 

Company; 

Workgroup E;\THESIS\SYSTEM.MDW 


Your workgroup is defined by the workgroup information file that is used 
at startup. You can create a new workgroup by creating a new 
information file, or join an existing workgroup by changing the 
information file that is used at startup. 


Create... 


Join.. 


Exit 


Figure 25: Microsoft Access Workgroup Administrator 



Figure 26: Workgroup Information File 



Figure 27: Workgroup Administrator 


Now that the program is installed and the system 
settings are in place, double-click on esf.mdb and make 
sure that the log in screen opens (Fig. 28) when the 
database starts. 
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Figure 28: Database Login Screen 

If a login screen does not appear when the program 
starts, repeat the installation process and ensure that you 
have not selected the system.mdw from a directory other 
than were the database is located. Upon initial install of 
the database the Admin password is adminl. Before you 
begin to use the database, the chosen administrator of the 
database should change the Admin login and add new logins 
for each member who will have access to the database. To 
complete these operations follow the instructions in the 
next section. 

4. Adding or Changing Security Logins 
a. Changing Login Passwords 

To change the administrator (Admin) or any other 

logins password, users must login as Admin. Once you have 
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opened the database and logged in, click on Tools on the 
main toolbar, then Security and finally. User and Group 
Accounts (Fig. 29). 
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Figure 29: Accessing Security Form 


Once users select the User and Group Accounts, a 
User and Group Accounts window (Fig. 30) will open showing 
the admin user. If this is the first time using the 
program than the Admin password should be changed so to 
ensure program integrity. To change the Admin password, 
click on the "Change Logon Password" and check to make sure 
that the User Name is Admin. If the user name is not 
Admin, than the user is not logged in as Admin and must 
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login again as Admin to complete the password change. If 
the username is Admin then enter adminl or any previously 
entered password into the Old Password text box and the 
enter the new password in the New Password and Verify 
boxes. Click on the Apply button and then select OK. Your 
new password is now in effect. To test the login, close 
the database and login again as Admin. If someone other 
than Admin needs to have there password changed or reset 
two methods can be used. The first method is to login as 
the user and then follow the procedures above or, method 
two is to have Admin clear the password of the user by 
selecting the users name under User and Name: and then 
click Clear Password. This will clear the users password 
and when they login they will only enter the login name 
without any password. To reset the password, have the user 
open the User and Group Accounts window (Fig. 29 and 30) 
and go to Change Logon Password and enter a new password in 
the New Password and Verify text boxes. 
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Figure 30: User and Group Accounts 



Figure 31: Changing Admin Login 

b. Add New Login 

To add a new login to the database, login to the 

database as Admin and open the User and Group Accounts 
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window by following the instructions from the previous 
section. Click on the Users tab (Fig. 30) of the window 
and select New to open the New User/Group form (Fig. 32) . 
Enter the users name (see warning below) in the name box 
and then enter a Personal ID value. This value does not 
need to be unique; however the combination of the Name and 
Personal ID value must be unique. Click on OK and the new 
user will be created without a password associated with it. 
To add the password, close the database and login as the 
new user, but do not add a password in the password block. 
When the new user is logged in, open the User and Group 
Accounts window and go to Change Logon Password. At the 
Change Logon Password window and verify that the User Name 
is the same as the new users and enter the new password 
into the New Password and Verify text boxes. 

Warning: When creating a login and password only 
use letters (a - Z) and numbers (0 -9). Do not use spaces, 
slashes or any other unusual character as they may change 
when the database is compacted or repaired. 



Figure 32: New User/Group Entry Eorm 

5. Description of Database Setup and User Interface 

The database is designed to reduce redundant data 
entry and allow quick access to necessary data. All 
queries, forms, reports and html pages are built on the 

information, which is stored in the many tables within the 
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database. Figure 33 shows the relationship between the two 
primary tables (Customer and Support) and the secondary 
tables that provide inputs to the primary tables. 



Figure 33: Database Table Relationships 

To fully understand how the database operates one must 
understand what makes up the database. The following 
sections will describe the tables, forms and reports 
generated by the database, 
a. Tables 

Tables are the foundation to any database. They 

hold the information for the database, as well as provide 

the initial formatting for how the data will be stored. 
From Figure 33, this database contains 15 separate tables 

with some additional tables being created and deleted as 

files are imported and exported. The following paragraphs 
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will discuss the key tables and what they are used for. 
Additionally, any special relationships between the tables 
and the impact that that relationship has on data entry 
will be discussed. 

The Customer table (Fig. 34) contains all the 
permanent and semi-permanent information about the vessel. 
This information includes the points of contact, telephone 
numbers, e-mail addresses, vessel limits, ship 
characteristics, vessel manning, operational commanders and 
possible mechanical problems associated with the vessel. 
This information should be maintained with the utmost 
vigilance since it is the table that will provide the most 
complete pass down between the vessel's missions. The 
Customer table has a one-to-many relationship with the 
Support table that requires that the customer entered into 
the Support table exist in the Customer Table. 
Additionally, the index on the ship name is set so that not 
duplicate entries can be entered into the table. This 
requires that every ship only be entered once the in the 
database and that its information be constantly maintained. 

The Support Table (Fig. 35) contains all the 
information about an individual support mission. Each 
record in the table will be given a mission route number 
(RTE) in order to provide a primary identifier between all 
the records in this table. Since support from 3 centers 
could potentially be in this table, every entry requires a 
route number for each support entry and this route number 
will be remain the same even when vessels is passed to 
another center. The Support table has many relationships 
with other tables that provide an input (drop-down list in 
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forms) into the data that is available in the Support 
table. 
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Figure 

34: Customer Table 
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Figure 35: Support Table 


The OPCON table, which feeds the Customer table 
with the appropriate operational commander, is used in 
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conjunction with the OPCONINFO table (Fig. 36) . These two 
tables have a one-to-many relation where the OPCON table 
provides the name of the operational commander and the 
OPCONINFO provides the point of contacts (POC) name, e-mail 
address and phone number. Since an OPCON can have several 
POC's the OPCON needed to be separated from the POC data. 
A POC of an OPCON cannot be added until the OPCON is 
available in the OPCON table. 



Field Name 

Data Type 

Description 


OPCON 

Text 

NAME OF OPERATIONAL COMMANDER 


POC 

Text 

POINT OF CONTACT AT OPCON STAFF 


EMAIL 

Text 

EMAIL ADDRESS OF OPCON POC 


PHONE 

Text 

PHONE NUMBER OF OPCON POC 






Figure 36: Operational Command Info Table (OPCONINFO) 

The final key table in the database is the 
SHIPLOC table that contains the related hyperlink products 
based on the geographic area of the customer's position. 
Again, a one-to-many relationship was created between 
GEOLOCATIONS and SHIPLOC to provide data to the Support 
table. The GEOLOCATIONS table holds the available 
geographic regions that a vessel can be in and the SHIPLOC 
table holds the locations with the products names and 
hyperlink to the product. 
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Eigure 37: Ship Position Product Link Table (SHIPLOC) 
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b. 


Forms 


Forms in a database are the primary means of 
entering data. By creating useful forms, the user can 
quickly and easily enter the necessary information and make 
the information available to the rest of the command. This 
database has many forms for entering the data into the 
tables. Some forms are individual forms that are connected 
to only one table, however many of the forms have forms and 
sub forms which use data from the first form to recall 
information from the sub form. In most case, where you 
find a one-to-many relationship between the tables, you 
will also find a sub form used to access the table with the 
many relationship. In Figure 38, the sub form is inside 
the box and is dependent on the SHIPNAME input box. 

The first form that a user interacts with is the 
startup form (Fig. 39) that controls the basic navigation 
through the program. From the startup form a user can move 
to the secondary forms to add a new customer, add new 
support, modify existing support, review incoming messages, 
import or export required files, view or print the turnover 
sheet, modify the administration forms or close the 
database. 
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Figure 38: 


Area 


Inside the Box is the 
Support Form 


Sub Form of the 
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Figure 39: Startup Form, Used to Navigate through 

Program 


The Add Customer form (Fig. 40) is used to enter, 
view or modify data about customers that either are or will 
be supported by OTSR. The primary purpose of this form is 
to provide history on vessels so that as personnel in the 
OTSR program turnover and are replaced by new routers, 
information on how a vessel were supported or what their 
standard limits are, can be obtained. This form contains 
much of the standard information that is available via web 
pages or "Janes", however if the information can be 
retrieved directly from the customer, the data is usually 
far more accurate. Almost all the controls on the form are 
text input where the data is typed directly into the text 
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boxes. The only exception to this is the Search by Ship 
Name drop-down box and the OPCON sub form. The Search by 
Ship Name control allows the user to select the customer 
that they wish to review. It also provides a way to 
quickly view all the customers to determine if a new 
customer needs to be added. The OPCON sub form is used to 
view all the POC's of the selected OPCON. To change the 
current POC use the navigation bar below the POC and PHONE 
header. For information on how to enter data into each of 
the text boxes, select the box and then look in the lower 
left-hand corner of the screen to see what is suppose to be 
in the box and what the format should be. 



ulvJK VkCjrfSI I'U’ ,_ ^ 

Figure 40: Customer Entry Form 
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The Support Form (Fig. 40) is the primary form 
that a router or OTSR tech will use while working with the 
data entry portion of this program. Because of the 
importance of entering data correctly, we will discuss each 
of the controls of this form in detail. This form is used 
for adding, editing and viewing all supported customers. 
Two versions of this form are available from the Startup 
form. Add New Support and Open OTSR Support. The Add New 
Support opens the form to a new record and the Open OTSR 
Support opens the form to the first record. Once you have 
opened the OTSR support form, new support can be added by 
clicking on the Add New Support button at the bottom left 
of the screen. 

The SHIPNAME drop-down box allows the user to 
only select customers, which have previously been added to 
the Customer table. If a customer is not available, 
minimize of close the Support form and then open the 
Customer form and add the new customer by clicking on the 
"Add New Customer" button. Once the customer information 
is added, close the Customer table and then maximize or 
reopen the Support Form and select the customer from the 
drop-down list. 

As mentioned in the Tables section, the RTE is 

required for all entries in the Support table. The RTE is 
made up of the INIT, the current year and the sequential 
support number. The INIT is the first letter in the 

commands location (S = San Diego, N = Norfolk, and Y = 
Yokosuka) and is set to default to the users value. The 
current year is set by using the systems clock, so 

depending on the time settings that one uses the clocks 
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could vary whether you are using local or GMT time. 
Finally, the Support Number is a sequential number that is 
set by the system by comparing the last value entered and 
adding 1. This value will reset to 1 upon the shift to the 
new year. These three values make up the RTF, which will 
remain the same for the remainder of the support for this 
track. Because these values are automatically entered when 
the new support is added, these three objects have been 
removed from the tab order and do not normally receive the 
focus. To change the value of the Support Number, select 
the text box under SUPPORTNUM and type in a new value. 
Remember: The next support value will add 1 to the modified 
entry so you may need to change that value if you are not 
adding numbers sequentially. 

The classification of the support is selected 
from a drop-down menu and is usually provided in the 
MOVREP, MOVORD or OTSR request message. Enter this value 
by typing the first couple of letters to the classification 
and selecting enter or select the drop-down list and choose 
the appropriate value. 

Both and STARTDATE and STOPDATE are entered by 
selecting the current status of the support. If the 
TR_SUPPORT changes from "PENDING" to "OPSNORMAL" or "12 
Hourly" then the STARTDATE will enter in a DD-MMM-YY 
format, where DD is day, MMM is month and YY is the last 
two digits of the Year. Additionally, the STOPDATE is 
entered when the TR_STATUS changes from an active type of 
support to "FINAL". Error checking has been created to 
check if the TR_STATUS has changed in a manor which would 
extend the support of remove a STOPDATE, such as mistakenly 
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selecting FINAL before one meant to. The tab order for 
these controls has also been removed to avoid data entry 
mistakes. 


As shown in Figure 38, the values from Limits to 
Customer Comments are associated with the Customer form. 
To edit any of these values, select "Open Full Customer 
Form", edit the necessary fields and then click on "Save 
and Close Form". The values you have edited will be 
modified and the new values will appear when you return to 
the Support form. 

The "PRIMARY METHOD OF REQ:" drop-down box is a 
selection to choose the method with which this particular 
support was requested. The standard choices for this 
object are usually. Movement Report (MOVREP), Movement 
Order (MOVORD), OTSR request, e-mail, or voice, however 
additional choices can be added by selecting the 
"Administration Eorm" and clicking on "Open Method of 
Request". Enter the new value on the next open line and 
close the form. 

The "MOVREP/Pri Request DTG" object is the Date- 
Time_Group of the request message, unless the request comes 
from a MOVORD message. If the request method does come 
from a MOVORD, enter the value in the "MOVORD DTG" box. In 
the cases when a customer provides both a MOVREP and MOVORD 
to request support, enter the DTG of the messages in the 
appropriate boxes. 

TR_STATUS is the current operational status of 
the vessel. The choices for TR_STATUS are: 

1. 12 Hourly: This status is used when the vessel 
has met or exceeded their current operational limits and is 
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under close watch from OTSR or under OTSR advisory or 
diverts (WEAX every 12 hours) . 

2. OPS NORMAL: This status is used when the vessel 

is underway and under their operational limits. 

3. IN PORT: This status is used for vessels that are 
still under OTSR support and in port for a short duration 
or OTSR can use this status as a reminder that the vessel 
is in port, but not currently under support. This would be 
helpful for sending sortie messages and ensuring that all 
vessels have been notified. 

4. PENDING: This status is used for those vessels 

that have submitted an OTSR request, but are not currently 
underway. 

5. EINAL: Status used when support for a vessel has 

completed. 

Additional TR_STATUS values can be added by modifying the 
"TR_Status Types" button on the administration form. If a 
vessel is under 12 hourly status than amplifying remarks 
can be added by selecting the cause for the support in the 
"12 Hourly cause" drop-down box. The purpose of this box 
is to provide a reason for placing a vessel on the current 
support. This box could be used for all operational 
status, however the standard reasons only include those 
that meet the OTSR advisory or divert criteria. 

The OTWE_SUPP box provides information about what 
support was requested and will be supplied to the vessel. 
The standard choices are: 

1. AVWEAX: This type is used when the vessel 
only requests aviation weather forecast messages and 
does not require OTSR services. 

2. AVWEAX/OPAREA: This type is used when the 
vessel is located within a local area OPAREA, however 
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due to operations requires special information from 
the aviation weather forecast message. 

3. OPAREA: Type used when vessel is operating in 
local OPAREA and only requires a standard shipboard 
forecast. 

4. OTSR: Type used for vessel transiting large 
ocean basins. 

5. OTSR/AVWEAX: Type used for vessels who are 
transiting large ocean basins and require an aviation 
forecast. 

6. OTSR/WEAX: Type used for vessels who are 
transiting large ocean basins and require a shipboard 
forecast. 

7. OTSR/OPAREA: Type usually used for vessels 
that are conducting operations that may be weather 
sensitive and require a more watch eye from OTSR 
(e.g., towing operations, TAGOS ops, diving 
operations) 

8. WEAX: Type used for vessels only requiring a 
shipboard forecast. 

9. SPECIAL SUPPORT: Type defined by local 
center, may be used for vessels not under Navy support 
but that may need notification if a storm is in the 
general vicinity of the vessel. 

10. SOI: Ship of Importance, could be a carrier 
or amphibious vessel with an embarked meteorology and 
oceanography division (OA division). Messages are not 
usually written to a vessel of this type; however OTSR 
coordination is required between OTSR and the vessels 
OA division. 

Additional OTWE Support options can be added by modifying 
the OTWE Support Types on the Administration form. 

The "Special Support" text box is a space to add 
any additional products that a vessel may have requested. 
If the vessel has an embarked met on board, and the met 
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needs satellite images sent daily or if the vessel would 
like a graphical WEAX, than this information could be added 
to the form. 

The "Ships in Company" text box is used to list 
additional vessels that will be transiting with the lead 
vessel. This condition could be permanent or temporary 
depending on the operations. 

The next section of the Support form is the most 
important portion of the entire form. This section is the 
departure and arrival information. If this information is 
not entered correctly, then vessels may be many miles from 
where the forecasting team expects the vessel to be. Both 
the departure location and the arrival location boxes are 
simply a text box used to type in the appropriate 
information received from the MOVREP or MOVORD. 
Additionally, each location has a departure or arrival 
time, respectively, that is inputted in a DDHHHHMMMYYYY 
format where D is day, H is hour and minutes, M is 3 letter 
month and Y is four number year. 

The next object in our discussion is the Location 
drop-down box which provide information on where the vessel 
is located in relation to METOC products that are being 
produced. In order to make the Electronic Ship Eolder a 
one stop shop location to review current support and 
valuable forecasting tool, the system must know where the 
vessel is located. Once the user select the region of the 
world that the vessel is in, he or she now has access to 
product links that have been established in the Ship 
Location table (SHIPLOC). As discussed in the tables 
section of this thesis, the linked products can then be 
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viewed to analyze the current situation or forecast the 
upcoming conditions. One can access the links by selecting 
the ship location, selecting the product name and then 
clicking on the View Product command button. 

The final user input to this form is the 
OT_Comments block which is used for the on watch router to 
provide comments to the next on coming watches. This block 
usually contains information about conversations that 
occurred during the watch, or possible routing scenarios. 
This information should be kept as current and in-depth as 
possible. 

Except for the command buttons that are labeled 
according to their task, the only other feature of the 
Support Form is the Quick Search section in the lower right 
hand portion of the form. In this portion of the form, the 
user can quickly access the needed RTF, Ship Name or view 
the current support by track status. Additionally, message 
traffic pertaining to the current RTE is available by using 
the Message buttons at the bottom of the page. 
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Figure 41: Support Entry Form 


The last major form that is used in the program 
is the MESSForm (Fig. 42). This form is used to access the 
many messages that are being added to the system daily as 
message traffic enters the command. The MESSForm is used 
to view the data which has been added to the Message table 
and formatted for easier reading than reading from the 
tables. One feature that is available from the MESSForm is 
the ability to enter new support while having the message 
displayed on the active screen. This helps to avoid some 
human error when translating the information from one 
screen to another or from paper to screen. To add new 
support from the MESSForm, find the message that you wish 
to enter into the database and select the button that 
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Figure 42: Message Form used to Review Message Traffic 

and Provide an Easy Method to Add New Support 
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Figure 43: New Support QuickForm used to View Message 

Traffic While Entering Support Data 


c. Reports 

The standard program comes with two primary 
reports, the OTSR Turnover Report and the Current Status 
Report. The OTSR Turnover Report is produced from several 
queries that organize the 12 Hourly, OPS Normal, INPORT and 
Pending vessels. This report contains the information 
needed to provide a proper turnover to the next watch (e.g, 
status of the vessel, departure and arrival locations and 
times, message DTG's, and turnover comments. The Current 
Status form is a much more abbreviated report that would be 
provided to the chain of command for general awareness of 
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the OTSR support. Using Access's report generation tool 
additional reports can be generated. 

d. HTML Display 

The HTML web pages are created based on the 12- 
hourly and ops normal customers. The pages are only 
generated if the particular messages or supporting html 
page is available. If for instance, a support vessel does 
not have WEAX or operational messages the WEAX and OPS 
links will not be available. If the vessel does not have 
any messages associated with its route number, than that 
ship will not be available on the support page, figures 44 
through 46 show representative html documents. 
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OTSR Index.html file 
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Figure 45: Individual Ship Support Page 
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Figure 46: Message Type Support Page 
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6 . 


Program Operation 


Operation of the ESF database is very easy with a 
little understanding of the basic operation of the program 
itself and Access 2000. The instructions in this chapter 
provide a very good overview on how the program should be 
used and how information should be entered into the 
program. As mentioned before, the ESF program can be 
operated from a network or stand alone PC. If the program 
is placed on a network drive, responsibilities for 
maintaining the data can be dispersed to several 
individuals, however one administrator can easily operate 
this program. These basic procedures should be followed in 
maintain the ESF database. 

1. Ensure that all current and near future customer 
have been added to the Customer Form. 

2. Ingest messages from the Message Parsing Program 
as often as the files are available. This keeps the number 
of ingest files to a smaller and more manageable number. 

3. Review messages frequently and utilize the New 
Support QuickForm to enter the available information from 
the message. 

4. For easier tracking of messages, be sure to change 
the message type from general to the appropriate value if 
the messages where not properly parsed. 

5. Update the support information by using the 
Support Form on the main startup form. Be as detailed as 
possible when updating the OTSR comments. 

6. Output html documents once all support data is 
updated by clicking in the "Create HTML Page" button from 
the startup form. 
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IV. TESTING AND EVALUATION 


In this chapter, the operational concept (OPCON), data 
flow and the test results will be discussed. The JMV and 
METCAST software modifications and concept of operations, 
along with the initial version of the Message Parsing 
Program were tested during Fleet Battle Experiment Juliet 
(FBE-J) in San Diego. A second test to evaluate the final 
version of the Message Parsing Program and the Electronic 
Ship Folders concepts was conducted in the classified lab 
at the Naval Post Graduate School (NPS). An Operational 
Concept (OPCON) was developed to describe how the various 
programs work in an operational environment. 

A. FBE-J TEST 

Tests were conducted during FBE-J between July and 
August 2002 to demonstrate ship track and HWD production 
and distribution. The distribution of XML data was tested 
between several JMV users as well as to the Polexis Web COP 
called Viewpoint. Additionally, the production and 
distribution of shape files was tested to ensure that these 
files could be used by ESRI viewers. Additional goals and 
requirements were established during FBE-J for the Polexis 
software; however, for this thesis only the product ingest 
and display of JMV products were tested. 

1. Operational Concept 

The OPCON for this test was to create HWD's and ship 
tracks using the MPP and JMV, publish these products and 
make them available for customer download. For this test 
the METCAST and Polexis software were used to download the 
finished products, however any web enabled application that 
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understands XML formatted messages can be used. . This 
test simulated the production of products from a typical 
METOC center and demonstrated how centers can collaborate 
to combine products and thus create a larger support area 
of collaborated products. This type of product production 
would be used to create a regional or global HWD where 
centers, facilities or detachments could provide inputs to 
a central coordinator who fuses the products into one. 
Depending on the claimancy CONOPS, this coordinator could 
be single "Super Center" that is responsible for half the 
world or a coordinated effort between commands on the same 
echelon level. In our current center architecture where 
each center is run by an METOC Captain and command 
boundaries are closely aligned with Eleet responsibilities, 
coordination is required to prepare products that overlay 
properly at boundaries. Today, coordination is conducted 
over the phone or over Internet Relay Chat (IRC) . By 
coordinating the boundaries prior to creating the product, 
producers can quickly negotiate and correct and differences 
at the boundaries. Once producers agree on the collaborated 
product the operational attribute is turned on and the 
product is now available to operational customers. 

2. Data Flow 

Eigure 47 describes the data flow from product 

generation to dissemination and then to product 

availability. Products are produced by a METOC center 
using JMV and published using METCAST (Eile|Publish Drawing 
for HWD's, the Publish button on the ship route editor for 
ship tracks). The publishing agent is called w-shove and 
is used to push the product with associated attributes to 

the METCAST server where the product is placed in a 
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channel. Once the product is in the channel, it is 
available for download by other METCAST clients and 
applications that used the METCAST discovery and 
subscription services. 


Data Flow for FBE-J Test 
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Eigure 47: 


Data Elow for EBE-J Test 


3. Results 

Initially MPP generated ship tracks were placed 
directly into the JMV tracks directory. The initial 
version of the MPP correctly parsed about 50% of the 
MOVREPs that it was fed. For those files that were not 
parsed correctly, manual modifications to the files had to 
be made. In most cases, the modified files corrected most 
file errors. For those errors that even manual corrections 
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could not fix, the tracks were manually entered into JMV's 
ship route editor. In general, errors with the MPP were 
due to improper formatting and additional spaces in the 
messages. Once the tracks were displayable in JMV, the 
messages were converted to XML and successfully published 
to the METCAST server 100% of the time. All published 
products that were successfully displayed on both JMV and 
Polexis displays. The ease of publishing, retrieving and 
updating was tested by creating separate Eastern and 
Western Pacific HWD's, publishing the products, and 
downloading them to a local system. Once the files were 
downloaded, both files were imported to the JMV display. 
In some cases, differences were created at the boundaries 
to verify that corrections could be made to the existing 
files and could be updated. In every case, the new product 
either wrote over the existing product or a new product was 
generated as desired. Eigures 48 through 63 graphically 
depict the process of producing two separate forecasts and 
merging them into one. 
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Figure 48: 


Creation of West Pacific HWD 


The first step in creating any combined forecast is to 
create the individual forecast pieces. During the exercise 
users produced a Western Pacific HWD that included 
parameters such as locations of highs, lows, fronts, wind 
barbs and other weather phenomena associated with the area 
of concern. Boundaries at the 180° or any other METOC 
center boundary were coordinated over the phone or using 
IRC chat. Once the points are determined the individual 
centers create the final product. 
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Figure 49: 


Publishing West Pacific HWD (Form 1) 


Figures 49 and 50 represent the process to upload the 
files to the METCAST server. For this test, the METCAST 
server was located at ENMOC; however, when the TEDS 
installs are completed at all the local METOC centers local 
server could be used. Eigures 51 through 53 show the 
process to publish the Eastern Pacific HWD. The process is 
the same as that performed for the Western Pacific area, 
except that the parameters in the two publishing forms 
contain slightly different attribute data. Once the HWD 
XML files are pushed to the server, the files are 
accessible from the METCAST channels dialogs (Eig. 54). 
Eirst, open the METCAST client and select the Options then 
Channels menu item. Download the product by clicking on the 
down arrow in Eigure 54 and selecting the whole channel or 
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a portion of the channel filtered by attribute (Fig. 55) . 
Once the file has been downloaded, select the map of 
interest and click on File|Import Drawing (Fig. 56 and 57) 
to add the first HWD file. To add the second drawing, 
click on File I Append Imported Drawing (Fig. 58 and 59) to 
add any number of other overlays to the existing graphic. 
By importing the file rather than adding it through the 
standard product selector, a user is able to modify the 
files (Fig. 60 through 62) and publish the changes (Fig. 
63) . 



Figure 50: Publishing West Pacific HWD (Form 2) 


81 


































0 170W 160W 150W UOW 130W 120W 110W 100W 90W 80W 



Figure 51: Creation of East Pacific HWD 



Figure 52: Publishing East Pacific HWD (Form 1) 
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Figure 53: Publishing East Pacific HWD (Form 2) 



Figure 54: Accessing HWD channel 
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Figure 55: Retrieving HWD Products 



Figure 56: Importing East Pac HWD 
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Figure 57: Importing East Pac HWD 



Figure 58: Appending WPAC HWD 
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Figure 59: Complete Pacific HWD with Mismatched 

Crossing Point 
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Figure 60: Mismatched Crossing Point (Blow-up) 
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Figure 61: Adjusting WPAC Product 
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Figure 62: Adjusting EPAC Product 
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Figure 63: Newly Created Product 


Finally we tested production, publication and 
subscription of ESRI shape files. Since ESRI's shape format 
arbitrarily assigns colors, an additional file is required 
to associate color with the published shape file. Depending 
on the version you are using, the format and file extension 
of this file differs. In ARCINEO version 3.2 this file is 
a .avl file and is generated by ESRI software. To make the 
shape file more useful, a .avl equivalent file needs be 
created by JMV to allow normal METOC symbology to be 
displayed properly. 

The shape files are created from the downloaded XML 
files. As described in Chapter III, the XML files are 
converted to shape by using an executable program, which is 
currently separate from JMV. These files were successfully 
created and then opened in ARCVIEW 3.2 for display. To 
solve the color problems, all HWD's are named the same and 
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the . avl files were created and associated with each HWD 
f lie. 

B. NFS TEST 

This test was conducted from the 2nd to the 6th of 
September with the purpose of testing the operation of the 
Message Parsing Program, the Electronic Ship Folder and how 
the outputs from the MPP (ship tracks and observations) 
were ingested and displayed in the current JMV 
architecture. 

1. Operational Concept 


The 

OPCON for this 

test was 

to provide a set 

of 

programs, 

which ingested 

operational 

message 

traffic 

and 

provided 

the output to 

a support 

tracking 

system. 

the 

Electronic Ship Folder, and graphical 

display 

program. 

JMV. 


Additionally, output from the database must be provided to 
area Fleet Commanders through an easy to use web page. 
This web page should contain, at a minimum, the currently 
supported vessels, a graphic of the track and links to the 
available message traffic. The last requirement was that 
the data be available in a format which could be combined 
with other OTSR center data to create a system that was not 
only interoperable, but could be used by a center as a 
backup tool, in the event, that another center needed them 
to provide backup services for an extended duration of 
time. By having a system of programs that can parse, 
track, disseminate and backup the currently used bits of 
OTSR information, the OTSR program would have a more 
operationally useful tool to conduct the business of 
supporting ships. This system would reduce the amount of 
time it took to review and enter various types of message 
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data and would reduce the manpower required to maintain 
current OTSR web pages. 

Manual data entry at each center should be limited to 
only those vessels that are currently being supported by 
that individual center. Messages being parsed and placed 
into the database as specific message types (i.e., WEAX, 
MOVREP, OBSERVATION, ETC.) should be reserved for messages 
that affect center supported vessels or those messages that 
are being sent by customers (i.e., observations or MOVREPs) 
that would be more difficult to separate. Since the 
parsing program can separate between active vessels (those 
being supported by the center using the database) and non¬ 
active vessels (those not being supported by the center 
using the database), these two groups of messages should be 
separated by directory and through database queries to 
reduce overlap between supporting and non-supporting 
centers. 

2. Data Flow 

Eigure 64 provides a graphic of the data flow from 
NPMOC through the processing path. The data flow required 
messages that were provided by the watch from NPMOC San 
Diego, and were transmitted to NPS via an ftp transfer. 
Messages are in an ASCII text format and where ingested 
into the MPP to determine the message type. Once the 
message type was determined, parsing criteria determined 
whether the particular message was to be parsed to the 
database, to JMV or moved to a new location. If a message 
type was not determined, then the message was parsed to the 
database and the file was moved to a general directory, 
located on the hard drive. As shown in Eigure 42, the 
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database output from the MPP provides the RTE (if 
available), SHIPNAME, DTG, Subject, message type, a link to 
the message file, and the parsed text of the message. This 
text could vary depending on the message type and the 
processing by the MPP. 

Once the messages were processed, the database import 
file (mess.txt) is imported by the ESE database to feed the 
Messages table. Database users then review the message 
traffic from the Messages Eorm. While using the Message 
Eorm, support can be added or updated by manually editing 
the support data using the information contained in the 
messages. While the user is reviewing the traffic, the 
message type and route number are reviewed for accuracy. 
This information is later used for the html web page 
creation. While the messages are being reviewed, the 
user's login is added to the userid field to allow the user 
to know when all the messages have been review. 

In addition to the files provided to the ESE database, 
files are also provided to JMV. The individually decoded 
MOVREP and decoded observation file are created and made 
available to the user to provide to JMV. The MOVREP files 
can be automatically added to the JMVWIN\NODDSELS\TRACK 
directory if the user selects this directory within the 
MPP. However, the decoded observations are added to the 
file jmvobs.dat and must be pasted into the appropriate SEA 
SYNOPTIC REPORT^OS^^^^^O^N^S''. JMV file within the users JMV 
area directory. Because JMV or METCAST have the potential 
to make many area boxes, the individual user will need to 
select the area they wish to add the files too. 
Additionally, only the most recent observations will be 
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kept in the JMV file since JMV is an operational system and 
is not routinely used for data archiving or reviewing 
historical events. Once the MOVREP is parsed and placed 
into JMV, the track is exported as a graphic and saved to 
the designated directory. For this test an images directory 
was added to the \JMVWIN\NODDSFLS\TRACKS directory. Once 
the file is created, the image is added to the tracks tab 
(Fig. 65) in the ESF database. These tracks are later used 
in the web page generation. 


Data Flow for NFS Test 
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Figure 64: 


NFS Test Data Flow 
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Figure 65: Ship Track display on Ship Track Tab of ESF 

database 


Now that the messages have been parsed, support 
database is updated, JMV files have been created and 
imported to the database, the web page generator is ready 
to be utilized. The web page is created by clicking on the 
"Create HTML Page" on the Startup form. This generates an 
index.htm file that provides a listing of all 12 hourly and 
OPS NORMAL ships under support, a SHIPNAME.htm file that 
contains links to the available messages for that ship and 
available track image, and finally a SHIPNAME_MESS.htm file 
that contains the links to the individual message files. 
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3 . 


RESULTS 


The overall operation of the existing system was 
satisfactory; however, as the test progressed several 
deficiencies in the program operation and design where 
apparent. The results of the individual programs will be 
discussed in this section with additional requirements to 
address deficiencies being added and discussed in Chapter 
V. 

a. Message Parsing Program 

Overall, the program parses messages correctly 
with both MOVREPs and Observations being decoded and JMV 
files generated. In general, MOVREPs were correctly 
processed about 70% of the time with observations that 
contained the BBXX identifier being parsed approximately 
90% of the time. Eor MOVREP files, errors were generated 
when incorrect latitude and longitude points were found for 
the ETA and ETD lines that only contained a port name and 
not a lat/long position or when other data was missing from 
the messages like ship's speed. As an example, a MOVREP 
was submitted with the track going from Okinawa to Sasebo, 
Japan. When the parser searched the port list file for the 
word Sasebo, it matched to the word Aseb. The program does 
compare latitude and longitude hemispheres; however, since 
Sasebo and Aseb are in the same hemispheres the file 
processed normally. Through this test, it is easy to see 
that much more detailed programming is required to parse 
the messages to a higher degree of completeness. All files 
that were run through the program were parsed into the 
database, except for when fatal errors occurred with the 
program. These errors usually occurred when twenty or more 
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messages where parsed at one time and incorrect data values 
or missing data were processed. Additional errors occurred 
when the program did not seem to initialize or reinitialize 
correctly with the right variables. These errors could 
easily be eliminated with a more complete understanding of 
Windows based programming in Visual Basic (program 
operations, file operations, etc.). 

ib. Electronic Ship Folder Database 

The operation of the database was very reliable. 
Messages were entered into the database very quickly and 
the OTSR support data could be updated very rapidly. Once 
all data was updated, the web pages were generated without 
any missing data and products were available. One problem 
was found with the ability to import some long messages 
into the message field of the Message table. 

In some cases, messages were truncated due to 
their length and only some portion of the message was 
available for review. Clicking on the link to the file and 
reviewing the text message could overcome this problem. 
One reason for this error was that Access table fields do 
not seem to except general ASCII string formatting and line 
feeds were not accepted to format the message properly. In 
order to fix this problem, extra spaces were added to fill 
all lines to 69 spaces and then the forms were adjusted to 
fit the font; Courier New, 10. This added unnecessary file 
size and exceeded the 65,536 character limit of a memo 
field. In most cases, METOC Messages were not affected by 
this error. 
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V. 


SUMMARY AND RECOMMENDATIONS 


A. THESIS SUMMARY 

Today's military decision makers have the challenge of 
receiving and processing more data than has ever been 
available before. In addition, decision makers must also 
make decisions faster than in the past since our 
communications, as well as our enemies systems and reaction 
times have been greatly improved. In order for METOC 

products and services to be viable to the decision makers, 
products must be fully integrated into the decision makers 
system. This thesis has investigated several means to 
improve the interoperability of METOC products and services 
by improving the tactical significance of our products, 
accessibility to our data, and interoperability between our 
internal command systems. 

In order to improve the interoperability of JMV and 
METCAST the following capabilities were added: 

1. Re-engineered the METCAST Server to allow multiple 
product types, as well as multiple product variations. 

2. Created communication path between JMV and METCAST to 
allow JMV overlays to be pushed to the METCAST server. 

3. Developed user interface to publish products from JMV 
and retrieve products from the METCAST server. 

4. Designed ESRI shape file export capability. 

In order to improve the interoperability of the Navy 
METOC OTSR program the following capabilities were 
demonstrated: 
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1. Created a message parser that scanned operational 
message traffic and provided output to the database and 
JMV. 

2. Upgraded existing database design to include all OTSR 
data, which is currently maintained in paper folders. 

3. Designed database format to be easily transferable 
between systems to provide backup capabilities between 
centers. 

4. Provided web output from database to provide quick 
access to all available OTSR data. 

B. RECOMMENDATIONS FOR FURTHER IMPROVEMENTS 

1. Improved Integration of Shape File Exporter 

The Current method of converting XML HWD's or Ship 
Tracks requires users to utilize a separate executable 
program requiring them to leave the JMV environment. Since 
this method is outside the normal operations of the program 
the procedures are much more confusing and increases the 
training requirements for the program. This programs needs 
to be incorporated into the current JMV architecture with 
standard Windows based programming structure to determine 
where the XML file is located and where the program should 
place the converted file. 

2. Better Integration of Message Parsing Program and 
Electronic Ship Folder Database 

In order to make the programs more efficient and more 
user-friendly, the Message Parsing Program and Electronic 
Ship Folder Database should be combined into a single 
program that handles the message parsing and data tracking 
duties of the OTSR Program. Improved error and data 
quality checking must to be utilized to ensure that the 
support data is entered into the database correctly. 
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Additionally, wherever possible, parsed messages should 
provide inputs to the support database automatically to 
reduce the time that users must manually enter data. As an 
example, MOVREP received by ships in centers AOR should be 
automatically entered with a notification screen telling 
the router that a new request has arrived. 

3. Improved Graphical Display Capabilities 

Since the current graphical interface utilizes the JMV 
display tools and does not have its own inherent system, 
the currently program is limited to displaying only those 
products that JMV displays. Since JMV is an operational 
system, it does not allow historical observations or tracks 
to be displayed simultaneously. One graphic that should be 
available is a display that contains all the observations 
that were received by a certain vessel for each route 
number. This not only provides verification of position, 
but provides and quick mechanism to verify forecasts. 
Additionally, other graphical products such as a ship track 
with current satellite data, or a meteogram using the ships 
observational data would be very valuable to OTSR routers. 
Appendix A displays several other products which this 
author believes should be incorporated into the graphical 
display from this program. 

4. Improved Statistical Analysis 

The current ESF database only provides access to the 
text messages and requires the user to manually parse a 
majority of the needed information within the message. 
Improved data parsing is required to allow the system to 
have access to specific data types that would be useful to 
the user of the system. As an example, observations need 
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to be parsed in finer detail, in order to track the 
individual parameters of the observation for trend analysis 
or graphical displays (e.g., graphic of changing wind speed 
and direction with time or sea and swell wave height data). 

C. OPERATIONAL IMPLEMENTATION 

All JMV and METCAST upgrades are under review to be 
implemented as operational products in the next SPAWAR's 
release. The ability to transfer HWD's and ship tracks 
between METCAST users is needed by all METOC Regional 
centers, not only to support internal requirements, but 
also to supply JMV created products to their local customer 
base. Dialogs have been initiated between the centers to 
provide necessary training and guidance to implement the 
system in the near future. 
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APPENDIX A: OTSR GRAPHICAL DISPLAYS 


This appendix shows several examples of products that 
should be available from an graphical display system that 
is incorporated in an OTSR routing support tool. 
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Figure 66: Modified Meteogram using Ship Observations 

and Model Forecasts 
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Figure 67: Ship Position with Model Pressures, 

Scatterometry Winds, Buoy Observations and Visual Satellite 

Images 



Figure 68: Satellite Overlaid with Model Surface 

Heights, Mean Sea Level Pressure and Surface Winds 
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Figure 69: Satellite with Significant Wave Period 



Figure 70: Satellite with Sea Surface Temperatures 
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